add unknown to DateTimeFormatTypes - #50402

I removed the lib update

So ECMA-262 has a similar issue with typeof since hosts can introduce custom values with differing typeof behavior; however, TypeScript assumes that only the well-known built-in strings can be returned from typeof because it catches issues.

I'm not as familiar with the APIs here, so can you give an idea of how code is intended to handle something like this value? (maybe it can be used as a test-case)

Daniel Rosenwasser (@DanielRosenwasser) yeah this is something different I believe that's not related to ecma262 typeof. The API here is that when you call new Intl.DateTimeFormat().formatToParts(new Date()) it returns a DateTimeFormatPart[] that has type & value. 1 of those types is called "unknown" (string literal, not related to TS unknown type).

See https://github.com/formatjs/formatjs/blob/main/packages/ecma402-abstract/types/date-time.ts#L187 for a reference. I do plan to backmerge formatjs types to TS cause the TS one is pretty outdated.

Okay, I see, so it is classifying each portion of a date string (docs). Whatever it can't handle, it just classifies as unknown. That seems reasonable.

I guess the reason that we didn't have this is because the "unknown" type was added as a normative change in 2018 in tc39/ecma402#245. That means that it ended up in ECMA-402 2019. Given that, I unfortunately think that this needs to be added to a new lib file called es2019.intl.d.ts. 😫

Daniel Rosenwasser (@DanielRosenwasser) done :)

It looks like you'll have to accept baselines - we baseline information about internal symbols which are unfortunately affected by changes to lib.d.ts ordering.

What does that mean 😅 ?

Oh, just run

npx gulp baseline-accept
git add tests/baselines/reference
git commit -m "Accepted baselines."

Thank you!